On Specifying Timeouts

This paper raises the question on how to specify timeouts in process algebra, and finds that the basic formalisms fall short in this task. Consider the following protocol for a mail server: Set a timer for an unspecified but finite amount of time, and try to send a message again and again until it either succeeds or the timer goes off. In the latter case return an error message. Optionally, someone may deactivate the timer before it goes off, in which case the system may run forever. My question is how to model this simple protocol by means of process algebra. Even though languages like CCS, CSP and ACP and their many variants have been around for twenty five years, it is still particularly tricky to do so. As this problem didn’t specify any real-time constraints it appears less natural to use a real-time process algebra. The specification should keep it completely open how long each activity lasts. In particular, there is no upper bound on the number of trials that are made before the timer goes off. Still we know that within a finite amount of time either the message is send successfully, or an error message is returned, unless the timer is deactivated. When abstracting, in part, from the timer, the process can be specified as set · μX.(fail · X + succeed + timeout · error) and a specification of the entire protocol (freely mixing ACCSP) could be set · ( μX.(fail · X + succeed + timeout · error)‖ timeout τ · timeout + deactivate ) . However, this specification leaves open the option that the process keeps failing forever: the standard operational semantics of ACCSP generates a transition system that features a path with infinitely many fail-actions and no deactivate (see Figure 1). One solution is to invoke Koomen’s Fair Abstraction Rule (KFAR) [1] to prove, by abstraction from fail, that either succeed or timeout will happen eventually. However, ∗Partly based on joint work with Frits Vaandrager.